🬤 rns.recipes

Forum / Showcase / Thread / Export

# Speakeasy

_Showcase · started by Janus on Thu, Jul 30, 2026 4:32 PM_

---

## Original post

**Janus** · Thu, Jul 30, 2026 4:32 PM

rns://fe3c891ff83352a3cebb4df434d01ab4/mirrors/speakeasy

https://www.github.com/comms-engineer/speakeasy

Speakeasy is a lightweight bulletin board and social hub server built natively on the Reticulum Network Stack (RNS). It adds structured, asynchronous forum-style threads, persistent posts, and topic boards to your Reticulum enclave.

It’s meant to be a convenient, easy-to-run feature for community nodes—a place to drop project updates, hold longer discussions, or post announcements that don't belong in a live chat stream.

Speakeasy is not a replacement for RRC (Reticulum's IRC protocol).

* RRC is great for live, real-time channel interaction between active peers.

* Speakeasy serves as a persistent "town square." It gives users a centralized place to browse topics, start threads, and catch up on discussions on their own schedule without needing everyone online at the exact same moment.

Reticulum is inherently decentralized and sovereign, which can sometimes make tracking ongoing topics tricky. Speakeasy provides an intentional, optional point of convergence for social interaction within an enclave.

Reticulum Principles in Practice

1) Cryptographic Identity - No user accounts, email sign-ups, or password databases. Posts and board interactions rely directly on standard Reticulum Identity keypairs to verify authorship.

2) Native Destination Addressing - The Speakeasy host exposes an RNS Destination. Routing and interactions happen entirely within the RNS network model rather than using traditional web ports, web sockets, or IP endpoints.

3) Lean Payload Overhead - Designed to keep wire payloads clean and compact, taking advantage of standard RNS primitives so it runs unobtrusively on modest node hardware.

4) Zero External Dependencies - Runs entirely inside Reticulum—no DNS lookups, external web servers, or third-party APIs required.

Please reach out to me with any feedback, suggestions, questions, concerns, critiques, etc.

LXMF: b5186a1b81b66f8ef423e087ed7d2a80

NomadNet: d57dbebbee44ca05fdd7272cf4b9e5f0:/page/index.mu

---

## Reply 1

**Zenith** · Thu, Jul 30, 2026 6:39 PM

If you can't bother to even write the README ***or your own post***, I'm not allowing you to promote your project here. Thank God whatever training data that LLMs use has an em dash fetish.


I'm going to make a formal post later because the slopware problem is getting out of hand. You can't try to promote something as a "standard" when YOU DIDN'T EVEN WRITE IT, LET ALONE LOOK AT WHAT THE LLM IS SPEWING OUT!

The tl;dr new requirements for posting LLM assisted (in full or part), projects will be:

- A LLM disclaimer usage

- 6 months of visible commit history

Otherwise, your post is getting deleted. There is zero excuse for this shit.

---

## Reply 2

**Zenith** · Thu, Jul 30, 2026 6:57 PM

https://rns.recipes/forum/showcase/rules-and-requirements-for-llmai-assisted-projects

---

## Reply 3

**Janus** · Thu, Jul 30, 2026 7:16 PM

Where exactly did I stay that it was a standard? I said I built on Reticulum's standards. I've got about 15 different projects going across work and real life that take a lot of time, and LLMs give people the ability to turn a concept into an MVP instead of letting it just stale as a good idea in the back of their head.

Your forum, your rules, just make them known.

---

## Reply 4

**Zenith** · Thu, Jul 30, 2026 9:50 PM

**Janus** wrote:

> Where exactly did I stay that it was a standard? I said I built on Reticulum's standards. I've got about 15 different projects going across work and real life that take a lot of time, and LLMs give people the ability to turn a concept into an MVP instead of letting it just stale as a good idea in the back of their head.

>

> Your forum, your rules, just make them known.

My reply came off as incredibly rude, but this has just been an ongoing problem for years now.

It's beyond frustrating to see this project swamped with just non-stop slop. Some functional, some borderline, some just existing for the sake of having a repo. Another person fed Reticulum through an LLM to launch a "Rat token" crypto scam just a few months ago. Fun!

Now, this is entering "that's just like your opinion man" territory but I will say this:

Reticulum doesn't solve any problems. There is nothing intrinsic to Reticulum that does anything that doesn't already exist. There's plenty of tools out there that can do exactly everything Reticulum does in some ways or all.

But problems aren't solved through software. Problems are solved by people. The same way a hammer doesn't build a house but the person using it does.

Reticulum offers a nice shared protocol that we, as people, (humans) can use to build things which have the potential to solve problems. It's a language that computers we use can talk to each other with.

You don't need Reticulum to build a network. Even a mesh network. Plenty of things existed before it. You could have built a mesh network using snail mail and printed PGP keys. Or with MQTT. Or regular TCP/IP. Or just organized volunteers forwarding traffic.

The common denominator in all of this, is that they have to be organized by people in agreement speaking the same language, using the same standards.

When LLMs first came around I was reminded of a short story called "The Library of Babel" by Jorge Luis Borges. https://en.wikipedia.org/wiki/The_Library_of_Babel

The very short tldr is that there exists a place holding an infinite, endless library that holds every combination of every sentence or string of words ever written.

With the ability for LLMs to spew out "code" (working or not) I wondered if or how free software and software licensing would work when it would theoretically be possible to make just about everything in some type of industrial scale.

Little did I know that LLMs would be a *Tower of Babel* too.


If you can just prompt an LLM to make a standard or protocol, regardless if it's good, what value does having a protocol even have? I'm active a bit over in Meshtastic community too and I've seen a dozen people trying to patch their Claude Coded or ChatGPT'd "meshtastic alternative". I can't even count all of those,

I like Reticulum because I think it's the easiest way to do it. There's strengths and weaknesses, but I believe it's the best tool for the job and most importantly lets all sorts of different mediums talk to eachother.

Now what does this long rant have to do at all with your post?

Absolutely nothing you made there couldn't have been done with LXMF. It's literally built to do that. In fact having a look at the code some parts are nearly identical.

I'm not saying this to disparage you, but it's just the truth. If you had built this on top of LXMF you would have had a store and forward functionality ready to go out of the gate and all you would need is tack on a little bit of logic to have messages signed by an RNS identity. That would mean one less thing for you to maintain and more to focus on, even if you were just using an LLM to write it.

And this is now one of three vibecoded "federated messaging protocols" I've seen just posted on this forum alone.

https://github.com/jrl290/RFed

I really appreciate at the least that RFed, while vibecoded, tried to keep at least some compatibility with LXMF and not just be one of 5 million different things that nobody uses, though I still disapprove of having any sort of protocol like this vibecoded and wouldn't recommend personally using it.

The main takeaway here is the ubiquity of software should also be taken into account when considering it's utility.

---